Typical operation of computerized applications such as those using Java 2 platform Enterprise Edition (J2EE) to incorporate Enterprise Java Beans (EJB) incurs process overhead for each and every EJB included in the application. Overhead is incurred at the start of the application in the form of start-up time delay and later during the life of the application through overall memory footprint. During a typical start-up of the application server the EJB modules contained within the application are typically examined, deployment descriptors typically parsed and home objects are typically instantiated and populated into the name service associated with the corresponding EJB container. As the application uses and finishes with the EJBs they are not released but are maintained. These EJBs are maintained within a pool of previously instantiated EJBs and re-used as required by the application. This subsequent pooling and caching of the already instantiated EJBs provides performance benefits during the processing of the application, avoiding the need to re-instantiate an EJB prior to re-use. This technique of initializing, loading and caching typically works well during the production mode of operation for the application. Performance is however obtained at the cost of resources in the form of initial application load time and ongoing memory footprint. Current techniques such as that just described typically load all the EJBs contained within the application at start-up, thereby increasing application start time and memory requirements.
An EJB container is usually responsible for registering unique look-up names within a Java Naming and Directory Interface (JNDI) namespace when the server starts and binding those names to home objects within the container.
A development environment typically has requirements differing from those of the production environment. In a development environment one needs to typically get a unit of work done as quickly as possible to verify operation of specific code elements of interest within the application. The development environment typically focuses on a smaller number of EJBs relative to the number of EJBs found in the application as a whole. Unfortunately the development environment must usually adhere to the same instantiation and maintenance practices as found in the production environment. Additionally a development environment is usually memory constrained not having access to the same amount of resource afforded the production environment.
Therefore what is required is a more effective way to create and operate a development environment using EJBs that allows for faster start-up while maintaining lower memory requirements as compared to that of a production environment.